Embedded systems are present in specialized computing devices, such as various turnkey products including, but not limited to, network components like nodes for switches, routers and gateways. Software building blocks of such embedded systems are known as modules. A module may implement some specific functionality. A module's behavior can be determined by a set of module configuration parameters. The parameters may be preserved in some form of non-volatile storage to be available after device power down/power up cycle. The saved parameters can be accessed and used to initialize modules during device start-up.
An operator issuing configuration change requests via some form of management interface may change them later at run-time and save. Modules in a device may not be not totally independent—some modules may use services provided by other modules. Therefore, during initialization, reconfiguration and shutdown the modules have to be acted upon in a proper sequence, as implied by the aforementioned dependencies. For example, a routing protocol like Open Shortest Path First (OSPF) operating in an OSPF module, needs Internet Protocol (IP) stack operating in an IP stack module. Consequently, for initialization and reconfiguration, IP stack module parameters may be set before OSPF module parameters are set, so the IP stack module may become active before the OSPF module becomes active. During shutdown, an inverted sequence may be needed: the OSPF module can shut down first, followed by the IP stack module. In this way, OSPF may send packets informing other network devices that it is about to de-activate via the IP stack module. In consequence, other network nodes may adjust their topology databases without disrupting network operation, which may otherwise happen when a network node simply disappears without any warning.
In embedded systems, the initialization and shutdown functions may be improperly structured, which results in lots of redundant coding and difficulties in reusing the code in different products. Initialization code can be combined with initial configuration routines, specifically coded to handle some format of registry or INI file, holding configuration parameters. When the format changes, the whole initialization code may have to be rewritten. Initialization and shutdown sequences may be hardcoded, so it is difficult to reuse the code on different products using different set of features (modules tend to be tightly coupled with such an arrangement). Initial configuration and run-time reconfiguration may be performed with a different code, which adds redundancy, increases testing complexity and can be generally error-prone. There is no general mechanism for ensuring a correct sequence of actions on initialization and shutdown.